Managing Security Within the Database Engine : Securables

1. Managing Server Securables

Server securables are the objects that you govern and manage at a server level. Before granting access to a securable, SQL Server ensures that a principal has the appropriate permission. Server securables also have to be distinctive on the server such that no two server securables have the same name. And only Windows and SQL Server principals can have permission to access server securables. Examples of server securables are as follows:

• Endpoints

• Databases

• SQL Server logins

The following sections will review the steps it takes to grant and deny access to server securables.

1.1. Granting Access to Server Securables

As we discussed in the previous section, Windows and SQL Server principals are the only principals that can be granted access to server securables. The following example shows you how to grant access to a database server securable.

USE master;
GO

GRANT SHUTDOWN,CREATE ANY DATABASE, ALTER ANY DATABASE,
VIEW ANY DATABASE TO apressSecurity;

The syntax for granting access to server securables will vary depending on the securable that you are managing. However, the basic idea is the same. You specify the GRANT clause, the permissions you want to grant, and a server principal in which to grant the permissions.

1.2. Denying Access to Server Securables

Denying access to server securables is similar to granting access to server securables. Using the previous example, we will prevent that user from anything besides viewing databases. The following example prevents the user from shutting down, creating, and altering databases:

Use master;
GO

DENY SHUTDOWN, CREATE ANY DATABASE, ALTER ANY DATABASE TO APRESSSECURITY;
GO

You can see from the preceding example the similarities between granting and denying access to securables. To deny access to server securables, you specify the DENY clause, the permissions you want to deny, and the server principal that you want to deny the permissions on.

2. Managing Database Securables

Database securables are database-specific objects that are accessed and managed by database principals. Unlike server securables that must be unique on a server instance, database securables can exist multiple times on an instance. However, the database securable must be unique within a database. Some examples of database securables are as follows:

• Application roles

• Database roles

• Assemblies

• Asymmetric keys

• Symmetric keys

• Certificates

• Contracts

• Full-text catalogs

• Message types

• Remote service bindings

• Services

• Schemas

• Database users

The following sections will discuss granting and denying permissions to database securables.

2.1. Granting Access to Database Securables

Granting access to database securables closely resembles granting access to server securables. The following example will grant access to database-level securables:

USE Apress;
GO

GRANT BACKUP DATABASE, BACKUP LOG TO APRESSSECURITY;
GO

After reviewing this example, hopefully you can see the similarities in granting permissions to securables in SQL Server 2008. Once you understand the options that are available to you, then you should be able to get as granular as necessary to control the access to database securables for your database principals.

2.2. Denying Access to Database Securables

Denying access to database securables is equally as easy as granting access. The following example will deny database principals access to database securables:

USE Apress;
GO

DENY CREATE ASSEMBLY, ALTER ANY ASSEMBLY TO APRESSSECURITY
GO

3. Understanding Schema Securables

With the new role of schemas in SQL Server 2008, schema securables are important to understand. Schema securables are collections of objects owned by a user. Unlike SQL Server 2000, multiple users can be a part of a schema. Multiple schemas can exist within the database, and each schema name must be unique. Within a schema, objects must have distinct names, but a database may have objects with the same name as long as the schemas are different. The following is a list of schema securables:

• Constraint

• Function

• Procedure

• Queue

• Statistic

• Synonym

• Table

• Type

• View

• XML collection

Now that we have shown you the objects that can be stored within schemas, let's talk about some of the usages of schemas.

3.1. Defaulting User Schemas

When creating a user, the option exists to set the default schema for the user. The default schema determines the default objects that are accessible by the user when executing queries. The purpose of assigning a user to a schema usually means that the bulk of the objects that user requires access to will be in that schema. That will save the users from having to specify the owner in all of the queries they execute. Granting a user access to a schema by default also ensures all objects created by that user exist in their default schema.

From a security perspective, you can grant access to a user in a schema and prevent the user from accessing any of the other objects in any other schemas in the database. Granted, there are times when users need to have permissions to other schemas and granting those permissions are easily accomplished. However, the new functionality of schemas enables you to keep users within their box or schema without having to force the permissions at the database level. The next couple of examples will provide you with more detail on how schema security works.

The example in Listing 1 shows you how to create a SQL Server login, how to create a database user with a default schema, and finally how to add the database user to a role.

Example 1. Script Used to Create a Login, to Create a User, and to Add the User to the db_datareader Role

USE master
GO

CREATE LOGIN apressWriter WITH PASSWORD = 'P@ssw0rd!' ,
CHECK_POLICY = ON,
CHECK_EXPIRATION = ON,
DEFAULT_DATABASE = Adventureworks2008
GO

USE AdventureWorks2008
GO

CREATE USER apressWriter
FOR LOGIN apressWriter
WITH DEFAULT_SCHEMA = SALES
GO

EXEC sp_addrolemember db_datareader, apressWriter
GO

If you log in using the recently created user, you will notice that you can query the tables within the SALES schema without specifying "Sales." Because the user has access to the db_datareader for the database, you can access the other schemas as well. In order to query those tables, you have to specify the schema and then the table or HumanResources.Employee. Now, create our own schema.

3.2. Creating Schemas

Creating a schema is simple and only requires a couple of steps. Review the following schema syntax:

CREATE SCHEMA schema_clause_name [ schema_element [...n]

First, you specify the name that you want to represent the schema in the database, and then you identify the owner of the schema. By default, the owner will be the creator if there is no change on the authorization of the schema. One of the interesting things about creating schemas is that you can create tables and views, as well as grant, deny, and revoke permissions all within the CREATE statement. Even if the table or view does not exist, you can go ahead and grant the schema permissions to it. The script in Listing 2 is going to create a schema, make the apressWriter user the owner of the schema, and remove the user from the db_datareader role.

Example 2. SQL Script That Creates a Schema and a Table, and Then Removes the Previously Created User from the db_datareader Role

USE AdventureWorks2008
GO

CREATE SCHEMA APWriter AUTHORIZATION apressWriter
CREATE TABLE APWriter.books
(bookId int,
 Title varchar(100)
)
GO

EXEC sp_droprolemember db_datareader, apressWriter
GO

What do you think will happen when trying to perform actions in the newly created schema? Can you query the newly created table? Can you create objects? Run the following commands to see what your results are.

SELECT * FROM APwriter.books

CREATE TABLE APWriter.books2
(bookId int,
Title varchar(100)
)
GO

SELECT * FROM APwriter.books2

The query results show that you can actually query the table and create objects in the schema that you own even though you do not have explicit database permissions. That is because you explicitly own the schema, which enables you to perform the actions. However, you have no rights to other objects within the database. Run the following:

SELECT * FROM Sales.CreditCard

You will get an error message that prevents you from accessing the table. Think about the security options that are available to you if you really start playing with schemas and what users can access.